In a typical Service-Oriented Architecture (SOA) environment in a computer network system, the use of third-party services is possible. This is especially so in the use of the SOA environment for web services, where a third-party service is any functionality offered, such as an application or software already existing, and a web service is a software component representing a set of specific functions that can be described, published and invoked over the network (typically the Internet) using open standards. The SOA environment enables software applications to be assembled using third-party or existing services, and only where absolutely necessary, to be built. This promotes reuse of the existing applications, and a paradigm shift in the way software is developed.
With the SOA environment infrastructure, application design and development requires less effort, which leads to less expensive software/applications. Software may also be built incrementally such that the software application may be developed as and when new services are required. Software may be rolled out with a much shorter lead-time, leading to more responsiveness to customers' needs. Additionally, applications may be customised with relatively little programming effort to an end user's needs. The end user may be an organisation.
The SOA environment provides a suite of services that can be aggregated or assembled, which in turn may require dependent services. The dependent services are usually pre-defined and potentially pre-coded into the source code during implementations, as shown in FIG. 1. FIG. 1 shows a block diagram of a conventional SOA arrangement 10 with a calling service 12 with a pre-identified dependency invocation 14 in communication with dependent services 16. With this conventional configuration the mapping and binding information are programmed and fixed during the design or implementation of the application. Amongst the elements that are fixed, for example:                1. Messaging protocol to be used, for example application programming interface (API)— based, Remote Method Interface (RMI), Simple Object Access Protocol (SOAP), JAVA Messaging Service (JMS), or the like;        2. Dependent service name or package that is to be used;        3. Operation or API name of the service to be used;        4. Signature of the operation/API that is to be used, including expected input and expected returned parameters; and        5. Data types expected between calling and invoked services.        
There is a subtle difference between operation signature and data type dependencies. Signature pertains to the declaration of expected inputs (including the number of inputs, sequence, etc) and output. Data type is about the type of parameters, for example, int, String, and the like. For example, in Java, there is a difference between Integer and int.
The concept of assembly of services in a SOA environment requires the dependent services to be available and running when needed. As such, if the dependent service(s) 16 shown in FIG. 1 are no longer available or are down, then the service in context is also not available. This brings about the problem of flexibility and reliability of the service in question. In other words, the service is only as reliable as the least reliable service(s) that it is dependent upon. Also, if the supported protocol or API signature, for example, changes in a dependent service 16, the service in context or calling service 12 needs to be changed as well. Furthermore, in a SOA architecture, the ability to replace a service with another service that is providing similar functionality, but without being tied down by the example of fixed elements specified and listed above is crucial to the concept of reuse and mix-match based on end user requirements.
Recent attempts have been made to address this issue, and to increase the flexibility and robustness of services. U.S. Patent Application Publication No. 2003/0,070,006 A1 published on 10 Apr. 2003 in the name of Nadler et al describes a development system providing extensible remoting architecture, and U.S. Patent Application Publication No. 2001/0,037,417 A1 published on 1 Nov. 2001 in the name of Meyer describes a method and system for dynamically dispatching function calls from a first execution environment to a second execution environment. However, both of these systems do not adequately address problems related to having a fixed messaging protocol that is used. U.S. Patent Application Publication No. 2003/0,070,006 tried to address this problem, but as this solution is based on generating code during runtime, the multi-protocol support must be predefined. U.S. Patent Application Publication No. 2003/0,070,006 has the problem of being restricted to the pre-defined protocol supported. U.S. Patent Application Publication No. 2001/0,037,417 is an implementation that is specific to C++ environment only; hence, this system doesn't handle multiple-protocol support issue as discussed in Item 1 at all. U.S. Patent Application Publication No. 2001/0,037,417 can only run in local environments.
Both of these published patent applications fails to address the problem of defining a virtual interface at design time and bind it to an arbitrary (needed) service at runtime.
However, there is no solution to the problem of providing services that can be mixed-and-matched at runtime instead of being tied-in during design or implementation phases. In this context, “runtime” means:                Occurring while a program is being executed, (http://www.computeruser.com/resources/dictionary/)        Occurring while a program is executing. For example, a runtime error is an error that occurs during program execution and a runtime library is a library of routines that are bound to the program during execution. In contrast, compile-time refers to events that occur while a program is being compiled (http://www.webopedia.com/TERM/r/runtime.html).        
There is a need for a solution to the problem of providing a system that enables a calling service to be implementation agnostic as well as insulated from changes of dependent services, preferably in an SOA environment.